\subsection{Daemon and event handling}
\label{sec:design_daemon}

We implement a global file system monitor as a UNIX daemon process.  $auditd$ will log all interesting file system events specified by $rules$, and these events will further be written into a log file.  By default, the log file is specified as $/var/log/audit/audit.log$.  Therefore, in order to track what happened, the daemon process needs only to watch changes of the log file.  What we need is a file system event, say a file has changed, and $inotify$ seems to fit our requirement the best.  These signals are generated because the events to be monitored have been registered with the $inotifyx.add\_watch()$ function.  The monitored $inotify$ events are extracted from the events queue by calling $inotifyx.get\_events()$.  Besides the normal initialization, the daemon process does nothing but register an event with $inotify$ and call the parser appropriately.  The parser will in turn parse the new-generated log and set extended attributes on related files. 

One goal of our system is to see how a user who might compromise the system violates the integrity of file protection.  One challenge in the whole design is how to track users' behaviors even if that user has attained root privilege.  In modern UNIX distributions, $sudo$ is what users normally use to act as root.  In this case, $auditd$ would log such events as done by root.  Therefore, in addition to normal auditing rules, another auditing rule is always in place to record who runs $sudo$.  In the event the modification is done by a root process, the audit log is additionally parsed to discover what user performed $sudo$.

It is easy to find out who actually touches some files by correlating the record for the file with the record for running $sudo$.  Although we cannot deny that in its current form a user with root privilege can clear the log file or even forge it, we believe this technique can still help on analyzing malicious user's behavior to some extent.  Parsing the whole log file incurs much performance overheads, thus a timestamp option is added to achieve incrementally log parsing.

% When a file is modified we are using a parser to examine who modified the file and when modified it. 
%We get the data from $/var/log/audit/audit.log$ file and we parse it into desired format as ${?path?, ?syscall?, ?exe?, ?ts?, ?uid?}$.  After taking the data that is created by $auditd$ daemon and parsing it, we can take what we would like to get at this stage.
